Brad,

My problem is I'm sometimes seeing the exact same hang WITHOUT a disconnect....

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> I will try my best to decipher what is going on.
>
>
>
>
>
>
>
> I did want to make a point to Ray as well as others that most real machines
> with motion controllers will not survive a single disconnect cycle(Fanuc,
> Osai, etc.) So it is pretty cool the Kflop can, at all.
>
>
>
>
>
> Under normal running circumstances, I do not think there will be an issue
> but nonetheless I will hunt the 'bug' down.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Thursday, January 26, 2012 1:41 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Hanging In dotNet
>
>
>
>
>
> Brad,
>
> I am about to post a dead simple test program that reliably induces this
> issue about one time out of 3 or so. It will be in my folder in the Files
> section in a few minutes. If you run, and disconnect/reconnect the board a
> few times, you'll find after 2-4 disconnects, the app simply hangs. If you
> interrupt it, it will be on that line with the DLL call I pointed out
> earlier every time. Note that at this point the board is fine - you can kill
> and re-start the app without re-connecting the board, and all is well.
>
> BTW - I do NOT have anything else running - just the test app itself.
>
> Hopefully this will enable you and Tom to kill this bug.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> >
> > I do occasionally get this as well (hanging on a card call), and I believe
> > only when KMotion.exe or KMCNC.exe is running as well. I think someone
> else
> > is getting a token and being selfish with it maybe?
> >
> >
> >
> >
> >
> > I have also had instances where the MotionServer will stay in the
> processes
> > and cannot be killed, resulting in the need of a CPU reboot.
> >
> >
> >
> > It does appear to work under normal conditions though..
> >
> >
> >
> >
> >
> > -Brad
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > Behalf Of himykabibble
> > Sent: Thursday, January 26, 2012 12:36 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: [DynoMotion] Re: Hanging In dotNet
> >
> >
> >
> >
> >
> > It appears to me something, perhaps in the DLL, is getting whacked. When
> the
> > board re-connects, I download and run my init code, then initialize some
> > I/Os and Persist Vars. One of the things that gets done is to initialize
> the
> > spindle controls - turning off both relays, and setting the PWM to zero.
> > Setting the PWM is done by running my SpindlePWM program on thread 2. The
> > new PWM value comes, in part, from values stored in Persist vars 90-92
> (for
> > SWord, SSO, and actual spindle RPM). The connection hang is coming from a
> > call to read the SSO word using WriteLineReadLine passing the String
> > "GetPersistDec 92". This var IS initialized before this call is made. On
> the
> > initial connection after my app is started, it works correctly every time.
> > After a disconnect/reconnect it goes into
> > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber,
> command,
> > ref response); and never returns. If I comment out that one line, then I
> get
> > an completely bogus error when I try to run the SpindlePWM program,
> telling
> > me it couldn't find the file ". That is a single double-quote. The path
> > being passed into CompileAndRunCoff is absolutely valid: @"C:\My KFLop C
> > Programs\KMotionCNC\KMotionCNCSpindlePWM.c".
> >
> > I'm stuck....
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > "himykabibble" <jagboy@> wrote:
> > >
> > > OK, I thought you had both indicated typical was lower.
> > >
> > > In trying to pin down the connection hang, I've discovered something
> > interesting. There seems to be an interaction between
> > KM_Controller.Connected and KM_Controller.CheckIsReady(). As I reported
> > yesterday, I can pretty easily get it in a state where Connected is true,
> > but CheckIsReady is stuck false, until I disconnect. I've if'd out nearly
> > everything in my app except the connection logic, and I frequently find
> > Connected does NOT go false when I pull the cable. And, when this happens,
> I
> > also do not get the disconnect dialog from KMotion. I added a
> > Console.WriteLine to show me my internal connection state, and the state
> of
> > Connected, and the failure is highly repeatable. But, if I ALSO invoke
> > CheckIsReady(), even though I don't USE the value returned, it seems to
> > always behave correctly. So it appears Connected does not get properly
> > updated under all circumstance UNLESS CheckIsReady() is invoked
> > periodically. Does that make any sense? Does it give any clues to what's
> > going on here?
> > >
> > > Also, when the hang occurs, there is a little green arrow next to the
> line
> > indicated below, stating that that line is NEXT to be executed when the
> CPU
> > returns from wherever it currently is. So it appears to be hanging within
> > the WriteLineReadLine DLL call.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > > >
> > > > I don't think that sounds too high at all. 2-3 ms may be the
> theoretical
> > > > round trip time, but once you add the non-deterministic Windows timing
> > and
> > > > the interop I think an average of 15 ms is excellent performance.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > > Behalf Of himykabibble
> > > > Sent: Thursday, January 26, 2012 10:41 AM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Hanging In dotNet
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I've frequently had my app just hang after a re-connect. If I stop the
> > > > debugger after the hang, it is ALWAYS at the point indicated by ==>
> > below:
> > > >
> > > > public string WriteLineReadLine(string command)
> > > > {
> > > > string response = "";
> > > > try
> > > > {
> > > > MarshalPre(ref response);
> > > > KM_dotnet_Interop_WriteLineReadLine(_InstanceHandle, _BoardNumber,
> > command,
> > > > ref response);
> > > > ==>MarshalPost(ref response);
> > > > }
> > > >
> > > > What does this mean? I can't step or otherwise continue from this
> point.
> > I
> > > > never see this without a disconnect/reconnect. I have to assume it's
> > being
> > > > influenced by something in my app, since I can't get it to happen with
> > my
> > > > connection test app. But I have no idea how to pin down the root
> cause,
> > > > since it all works fine as long as I don't go through (usually
> multiple)
> > > > connect/disconnect cycles.
> > > >
> > > > I'm also seeing typical turn-around times for UpdateMainStatus()
> > averaging
> > > > 15 mSec, as measured using this code:
> > > >
> > > > Stopwatch Watch = new Stopwatch();
> > > > Watch.Reset();
> > > > Watch.Start();
> > > >
> > > > KMController.UpdateMainStatus();
> > > >
> > > > Watch.Stop();
> > > > Console.WriteLine("UpdateStatus: " + Watch.ElapsedMilliseconds +
> "\n");
> > > >
> > > > The range of numbers I see is from a low of 2-3mSec, to a high of
> about
> > > > 30mSec. Isn't this awfully high? You've both told me it should be
> > 1-2mSec,
> > > > but I almost never see it that low. Running my minimal connection test
> > app,
> > > > I see similar, though slightly shorter, times, though there is more
> > > > variability there.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>